1. Field of the Invention
This invention relates to computer programs. Particularly, this invention relates to computer programs for building installation software, such as cross platform installation software.
2. Description of the Related Art
InstallShield Multi-Platform (ISMP) is a software tool that allows application developers to package their products for installation on multiple platforms. The software provides a graphical build environment that allows application developers to create an installation for their products for multiple different operating system platforms, e.g. AIX, WINDOWS, LINUX, SOLARIS, OS/400, HP-UX, and MacOS Support for any one of these operating system platforms can be readily enabled by selecting a checkbox in the graphical builder.
As is known in the art, Java Beans is a portable, platform-independent software component model written in Java. They allow developers to write reusable components once and run them on any operating system platform. The beans themselves are Java classes that can be manipulated in a visual builder tool and composed together into various applications. Any Java class that adheres to certain property and event interface conventions can be a bean.
ISMP provides a facility to create custom beans to extend the functionality for user specific requirements. These custom beans are written in Java and used to extend ISMP provided bean classes. To be available to the installer at run time, all the custom beans classes and the classes that these beans depend upon, must be added to the install packages, e.g. in a Java archive (JAR) file. To facilitate adding the classes to an archive with ISMP, the custom beans typically override the regular build method and invoke the archive builder support for the custom beans to be added in an ISMP project (e.g. the archive builder support method).
Unfortunately, ISMP builds involving such custom beans are slow. For example, more then one bean may the use same classes. However, all these beans need to add these same classes to the archive. In addition, one project may have more then one instance of the bean. For each of these, the archive builder support method is called. This call requires excessive processing which includes verifying the class file existence and accessibility at the build time. In addition, the call includes calculating the class file size. Repeating this processing for duplicated classes unnecessarily adds to build time because the details of a given class file does not change during a build.
Another drawback of ISMP build involving customs beans is that the custom bean class or the classes used by beans may have inner classes. In additon, they may extend other classes or implement interfaces and/or use other classes for field, method and constructor arguments, exceptions and/or return types. These are dependent classes which need to be available to instantiate and use the original class. This implicitly means that writing of the custom bean requires additional calls of the archive builder support put class method for these dependent classes. That it turn requires the custom bean writer to be aware of implementation details of the classes being used in the custom bean.
As the dependent classes of a custom bean class may have similar dependencies (and recursively so on) of their own, the custom bean writer needs to be aware of the implementation detail of the entire class hierarchy. Furthermore, because it may be difficult or impossible for the custom bean writer to know details of the implementation of third party code, there is a risk of not having some of these dependent classes available during the execution of the install. Consequently, some necessary classes may be overlooked and the execution of the install may failing unexpectedly.
The conventional technique for dealing with the difficulties described above is for the custom bean writer to explore all the classes and get familiar with the class hierarchy (which may even require reverse engineering the code) and then add the Archive builder support method calls to include all the required dependent classes. However, this is a tedious process as the bean writer must manually analyze the class structure and include the necessary classes. Another conventional technique involves adding all the the third party supplied JAR files which comprise all the dependent classes. This approach has an big drawback of making the install distribution package excessively large, as the JAR files may include many more classes than are required by the custom beans.
Some other developments involving software installation utilizing Java have also occurred. Some examples are described hereafter.
U.S. Patent Application 20,020,108,099, published Aug. 8, 2002, discloses a process for developing an Enterprise JavaBean (EJB) component by analyzing a business domain to generate functional requirements that models the business domain. The functional requirements are transformed into an EJB component model, preferably using a UML drawing tool. The resulting EJB component is then built from the EJB component model that encompass the business functionality of the business domain. The process enables the user/developer to research business problems or domain (i.e., business project) and transforms them into EJB components.
U.S. Patent Application 20,050,125,788, published Jun. 9, 2005, discloses a method of installing software applications using a wizard-based installation package (for example, built using “InstallShield”). The installation package is defined declaring a discoverer bean, a producer bean, a consumer bean and a debugger bean into the wizard tree (while the product tree is left empty). During the installation process, the discoverer creates a working queue dynamically, inserting the installation operations that are needed for reaching a desired configuration (defined in a descriptor of the software application) from a current configuration (detected at run-time). The consumer executes the installation operations defined in the working queue in succession. Whenever an error condition is detected, the installation process is suspended and the debugger is invoked. An administrator can browse an execution log of each installation operation and update any wrong operative parameter. The installation process is then resumed without having to repeat the installation operations already executed.
U.S. Pat. No. 6,473,766, issued Oct. 29, 2002, discloses a product action bean for updating lines and keywords in computer system configuration flat text or ASCII files, which is especially useful for during installation of software applications on computer systems. In its embodiment as a Java bean, it is customized and configured using a visual application builder across multiple computing platforms. The primary bean is a container bean, which includes an engine, and which provides a graphical user interface (“GUI”) that developers can easily specify the required changes along with the file name to be changed when an application is installed or uninstalled. The container bean also contains a set of action beans which perform operations to modify the ASCII file, such as finding strings or lines, adding strings or lines, and deleting strings or lines. The specified actions are performed as a “unit of work” in the customized bean. Alternate classes of objects for modifying text files may be included in the container bean to expand the action options available to the developer.
In view of the foregoing, there is a need in the art for systems and methods to perform more efficient and more reliable builds for installation software, particularly a multiplatform software installation. In addition, there is a need for such systems and methods when custom beans are employed in a Java implementation. There is still further a need for such systems and methods to function automatically, minimizing the need for a programmer to manually analyze the build structure. As detailed hereafter, these and other needs are met by the present invention.